Columbia Kermit/kermit.zip/newsgroups/misc.19950329-19950528/[e-mail]_Fri May 5 13:21:49 1995.msg

Internet Message Format | 2020-01-01 | 4KB

Received: from apakabar.cc.columbia.edu by watsun.cc.columbia.edu with SMTP id AA08095
  (5.65c+CU/IDA-1.4.4/HLK for <[e-mail]>); Fri, 5 May 1995 22:37:30 -0400
Received: by apakabar.cc.columbia.edu id AA02709
  (5.65c+CU/IDA-1.4.4/HLK for kermit.misc@watsun); Fri, 5 May 1995 22:37:28 -0400
Path: news.columbia.edu!spcuna!solaris.cc.vt.edu!hookup!news.moneng.mei.com!uwm.edu!vixen.cso.uiuc.edu!howland.reston.ans.net!pipex!warwick!bham!B.A.McCauley
From: [e-mail]
Newsgroups: comp.protocols.kermit.misc
Subject: Re: C-Kermit 5A(190) server mode problem
Date: 05 May 1995 13:21:49 GMT
Organization: The University of Birmingham, UK.
Lines: 82
Message-Id: <[e-mail]>
References: <[e-mail]>
    <[e-mail]>
    <[e-mail]>
Nntp-Posting-Host: wcl-l.bham.ac.uk
In-Reply-To: [e-mail]'s message of 4 May 95 17:33:22 MDT
Apparently-To: [e-mail]

In article <[e-mail]> [e-mail] (Joe Doupnik) writes:
>In article <[e-mail]>, [e-mail] writes:
>> In article <[e-mail]> [e-mail] writes:
>>>When the terminal is MS-KERMIT 3.13.0 it works fine when the terminal
>>>is C-Kermit 5A(190) then the generic finish command is ignored (it's
>>>not even logged in the packet log). My software first sends a "N"
>>>packet (in case the server had send a "S" and I had missed it)
>>>followed by an "E" packet and finally sends an "I" packet, after which
>>>C-Kermit will accept the "GF" packet.
>    Hmmm. I don't think you want to do all that. First, a Kermit
>server sits around waiting for a client to start a session and make
>a request. It does NOT send S packets while waiting. It may send NAKs
>now and then to stimulate old clock-less Kermit clients. E packets are
>powerful things because they terminate a file transfer operation; don't
>use unless *really* needed.

I know all this and I agree that my client may not take the ideal
approach to attempting to recover the situation. This is not the issue
here, what I want to know is why C-Kermit is ignoring the GF packet in
the first place.

>    C Kermit did see the GF packet, ACK'd it, and logged both, as
>your C Kermit packet log below clearly shows.

No it does not. Look again.

> Your E packet also shows.

And like I said this was sent to force a reset *after* the server failed
to respond to the GF packet. After this reset the next GF packet worked.

>    Now then, I've lost track of what was the real question.

What happened to the first GF packet? Not the one I sent after
resetting the server.

>>>Here is C-Kermit's packet.log (long data packet truncated).
>>>
>>>r-00-00-
0 I~\ @-#Y2 J 5S#
>>>s-00-00-
5 Y~* @-#Y2~^!5$0___CX
>>>r-00-01-
% GD S
>>>s-00-01-
5 S~* @-#Y2~^!5$0___AP
>>>r-00-01-
0 Y~\ @-#N2 J 5S(
>>>s-01-01-
*!Xls -l );
>>>r-01-00-
$!Y">
>>>s-02-00-
2"A."U1"#AMJ*!A@ -T
>>>r-02-00-
$"Y"?
>>>s-03-04-
 #D08Rtotal 5349#M#Jdrwxr-xr-x   2 bam      staff        1024 Apr  5 12:54 backup.home#M#Jdrwxr-xr-x   2 bam      staf
>>>r-03-08-
$#Y"@
>>>s-04-08-
$$Z"B
>>>r-04-09-
$$Y"A
>>>s-05-09-
$%B"+
>>>r-05-09-
$%Y"B

This is where I sent the GF packet. What happened to it? (BTW this is
reproducable, it's not a comms problem).

>>>r-00-19-
# N3
>>>#-00-19-<echo:ignored>

What does this mean? This looks nothing like the last packet!

OK my client is desparate now so it sends an E and I packet to reset
the server.

>>>r-00-29-
E EToo many retries (expecting SXBFY)U
>>>r-00-30-
0 I~\ @-#Y2 J 5S#
>>>s-00-30-
5 Y~* @-#Y2~^!5$0___CX

OK the server is listening again so let's try the GF command.

>>>r-00-31-
$ GF4
>>>s-00-31-
# Y>

This time the GF packet worked.
--
    \\   ( )   No Bullshit!   | Email: [e-mail]
 .  _\\__[oo       from       | Phones: [phone] (home)
.__/  \\ /\@  /~)  /~[   /\/[ |  [phone] (voice) 2175 (fax)
.  l___\\    /~~) /~~[  /   [ | PGP-fp: D7 03 2A 4B D8 3A 05 37
 # ll  l\\  ~~~~ ~   ~ ~    ~ |         A1 93 FE EA BE E3 2A 91
###LL  LL\\ (Brian McCauley)  | More: finger [e-mail]